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(57) ABSTRACT 

A system, method and computer program product for ifian^ 
\^3ging diagnostic and performance information for commu- 
nications system terminal endpoints (TEs) communicating 
over an Internet Protocol (IP) network. The TEs communi- 
cate by connections that are voice, modem, facsimile, video, 
data transmissions, or the Ukc. A Diagnostic Supervisor-(DS) 
transmits Diagnostic Configuration Messages (DCMs) to the 
TEs. The TE's generate Diagnostic Messages (DMs) bafed 
;on diagnostic information, including error statistics, voice 
statistics, facsimile statistics, video statistics, data statistics, 
or the Uke, concerning IP network connections in which the 
TEs participafe The DCMs instructs the TEs how to format 
and when to transmit DMs. The DMs are transmitted by the 
TEs to the DS. In a system with more that one DS, the TEs 
can transmit DMs to the plural DSs, other TEs or any 
network devices. The DS can be programmed locally or 
remotely to send various types of DCMs. The DS can also 
be programmed locally or remotely to provide diagnostic 
reports based on DMs to network users or to the network 
administrator. Diagnostic information is used for disconnect 
supervision, answer detection, attendant supervision, biUing 
management, rerouting of IP connections to the PSTN, and 
the like. 
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SYSTEM, METHOD AND COMPUTER locally or remotely to provide diagnostic reports based on 

PROGRAM PRODUCT FOR DIAGNOSTIC DMs that were delivered to network users or to the network 

SUPERVISION OF INTERNET administrator, for example. 

CONNECTIONS In one embodiment of the present invention, the system 

5 can reroute an IP network connection between two or more 
TEs to the public switched telephone network (PSTN) based 

BACKGROUND OF THE INVENTION diagnostic information. Rerouting can be initiated by 

1 Field of the Invention ^ or by a TE with DS capabilities. Alternatively, 

rr-. . 11 1 * . - J rerouting can be initiated by a TE user, the network admin- 

This mvenuon generally relates to communications, and ■ . . • . j * 

„ , , J J , istrator or a communications system attendant, 

more specifically to a system, method and computer pro- ^ ^ 

gram product for diagnostics supervision of Internet ^^^^^^^^^ embodiment of the present invention, DCMs 

connections, such as VoIP calls. configured to mstruct TEs to transmit DMs including 

2 Related Art silent packet diagnostic information. The silent packet diag- 

nostic information can be used to provide the system with 
TTic uses of the public Internet are very diverse. Ausc that 15 disconnect supervision of IP connections by determining the 
has recently gained much attention is Voice-over-Internet average number of silent packets detected over a period of 
Protocol (VoIP) technology, which involves using the public time, or by a total count of silent packets. 
Internet or a private IP network to carry voice calls, either ^^^^^^^ embodiment of the present invention, 
parually or complctdy bypassing the public switched tele- p^Ms can be configured to instruct TEs to transmit DMs 
phone network (PS IN). 20 including non-silent packet diagnostic information. The 
VoIP, as weU as video conferencing, has been used by non-silent packet diagnostic information can be used to 
computer hobbyists to place no-charge (and typically low- provide the system with answer detection supervision of IP 
quality) calls over the Internet, using microphones, video connections by determining the average number of non- 
cameras, and speakers connected to a personal computer sHent packets detected over a period of time, or by a total 
(PC) audio card supported by audio/video software. Com- ^ count of non-silent packets. 

mercial applications of VoIP technology are now emerging. another embodiment of the present invention, the 

Various types of services can be provided usmg VoIP, diagnostic information comprises a plurality of parameters 

includmg enterprise toH bypass, IP-based IntereXchange defined by the DCMs and the DMs. A DS or TE can be 

Carrier (IXC; long distance) service, and IP-based local programmed to determine an average number of occurrences 

telephony. ^^^^ plurality of parameters or a total number of 

A drawback of existing implementations is the use of the occurrences of one of the plurality of parameters. 

User Datagram Protocol (UDP) to provided bandwidth not Que embodiment of the present invention provides for 

available using TCP UDP is the connectionless transport attendant supervision of the communications system. In this 

protocol m the TCP/IP protocol layers. UDP does not embodiment a human attendant provides real-time response 

provided for error detection/correction or any other quality the diagnostic information. Alternatively, biUing manage- 

of service (QoS) within the existing protocol. Thus, the ^^^^ performed for the communications system 

quality and connection of calls is uncertam. ^^ing diagnostic information. For example, billing of an IP 

What is needed is a technique to better control Internet network connection, or a connection rerouted to the PSTN, 

connections, such as VoIP calls, by providing real-time is performed based on the diagnostic information provided 

information about the quality of inbound and outbound by DMs. 

voice, modem, facsimUe, video streams, and the like. ^ preferred embodiment of the present invention, the 

SUMMARY OF THE INVENTION comprises a Configuration Manager, a Report Manager, 

,^^-ngrs^,,_, ^ Real-Time Response Manager, and an Input/Output (I/O) 

The present inv^enii^dif^trdltoMsySS^ 45 Manager coupled to the IP network and the PSTN. The DS 

computer progr ani p r^^^for^^managing diagnostic and can also include a communications system so that it can 

P^I^Sw^^^^^^^^^*^^'^ communications system termi- function as a TE, 



<™s) communicating over an Internet Proto- p^^her features and advantages of the present invention, 

collflPT^twork. The TEs communicate by connections that ^s well as the structure and operation of various embodi- 

are voice, modem, facsimile, video or data transmissions. 50 j^^^^^ present invention, are described in detaU below 

A Diagnostic Supervisor (DS), which is capable of being vvith reference to the accompanying drawings. 

coupled to the communications system, transmits Diagnostic ^^„™™™^vt r^,^ 

Codiguration Messages (DCMs) to the TEs. Thl TE's B^IEF DESCRIPHON OF TOE DRAWINGS 

generate Diagnostic Messages (DMs) based on diagnostic The present invention is described with reference to the 

information, including error statistics, voice statistics, fac- 5s accompanying drawings. In the drawings, like reference 

simile statistics, video statistics, data statistics, or the like, numbers indicate identical or functionally similar elements, 

concerning IP network connections in which the TEs par- Additionally, the left-most digit(s) of a reference number 

ticipate. The DCMs instructs the TEs how to format and identifies the drawing m which the reference number first 

when to transmit DMs. The flexibility afforded by the DCMs appears. 

allows large amounts of customized diagnostic information 60 FIG. 1 illustrates a system for communicating diagnostics 

to be delivered in a non-intrusive manner by limiting the or other feedback concerning IP connections from one or 

transmission of diagnostic information only when required. more terminal endpoints (TEs) to a Diagnostic Supervisor 

The DMs are transmitted by the TEs to the DS. In a system (DS) according to an embodiment of the present invention, 

with more that one DS, the TEs can transmit DMs to the FIG. 2 illustrates various types of TEs in a system similar 

plural DSs, other TEs or any network device. 65 to that depicted in FIG. 1 for communicating diagnostics or 

The DS can be programmed locally or remotely to send other feedback concerning IP connectioos according to 

various types of DCMs. The DS can also be programmed another embodiment of the, present invention. 
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FIG. 3 illustrates a distributed diagnostics management delay-sensitive traffic such as voice than lo less-delay- 
system of servers and clients that communicate via the sensitive data. These features can be provided by resource 
Internet according to another embodiment of the present reservation protocol (RSVP) or by other mechanisms that 
invention. enable network administrators to deliver trafiSc defined as 

FIG. 4 illustrates an exemplary architecture of a DS s high priority (such as video conferences) before less lime- 
according lo an embodiment of the present invention. sensitive traffic. 

FIG. 5 illustrates an exemplary architecture of a Configu- VoIP-to-PSTN Gateway 
ration Manager according to an embodiment of the present 

invention. ^ VoIP-to-PSTN gateway is typically used to permit 

HG. 6 illustrates an exemplary architecture of a Report '° ^^^^^ telephone devices not merely those connected 

Manager according lo an embodiment of the present inven- ^« gateway functions to convert the calls 

^Qjj between analog voice and packet data and translates 

^„ ^ .„ , r 1 between the VoIP call control system and the protocols used 

no 7 Illustrates an exemplary architecture of a Real- ^ ^^^^^ gj ,j ^ ^ ^^^^y 

Time Response Manager (RTRM) according to an embodi- 15 „ , , , . . 7 . i . 

ment of thee present invention. Most VoIP-bascd lXCs provide a bank of inco^^^ 

^ .„ , I, lines at each of their points of presence (POPs). To initiate 

FIG 8 Illustrates an exemplary architecture of a TE a network call, a user calls the VoIP gateway from a standard 

according to an embodiment of the present invention. ^^^^^^ icl^^hont or fax machine. Hie gateway provides 

HGS. 9A-C illustrate exemplary flow diagrams for IP ^ij^cr a simulated dial tone or some other tone. The user 

connection rerouting to the PSTN according to the present 20 enters the destination telephone number as well as a personal 

invention. identification number (PIN) for billing. The IXC establishes 

HG. 10 illustrates an exemplary flow diagram for dis- an IP connection between the user's local POP and another 

connect supervision or answer detection of IP connections pOP close to the calFs destination. The destination gateway 

according two embodiments of the present invention. then places a standard local call to the final destination, and 

FIG. 11 illustrates an exemplary flow diagram for moni- the voice or fax link is created. In practice, an Internet 

toring connection parameters of IP connections according Exchange Carrier (IXC) system typically would be more 

further embodiments of the present invention. integrated into the local phone network than suggested here, 

FIG. 12 illustrates various types of TEs in a system for so that the subscriber would dial the long-distance phone 

attendant supervision of IP connections according to an number, and the calling number as well as the call itself 

embodiment of the present invention. would be transmitted transparently over the local phone 

FIG. 13 illustrates various types of TEs in a system for network to the POP. 

billing management of IP connections according to an g jj 3^3 1^^^^^^^ Telephony Standard 
embodiment of the present invention. 

35 H.323 is an Internet telephony standard from the ITU-T 

DETAILED DESCRIPTION OF THE tjjat defines multimedia communication over packet- 

EMBODIMENTS switched networks that do not provide guaranteed QoS. 

I OVERVIEW H.323 is an extension of the original H320 standard, which 

specified criteria for video conferencing over ISDN and 
The following section is an overview of basic Internet- other circuit-switched networks. H323 extends H.320 for 
related concepts, as discussed in PricewaterhouseCoopers' use on networks such as the Internet and private IP networks. 
Technology Forecast: 1999 (PricewaterhouseCoopers Tech- H.323 is adapted to support many aspects of multimedia, but 
nology Center, Menlo Park, Calif., 94025; order #TC-01- requires only voice and, as such, generally is regarded as the 
09). standard for VoIP. H.323 defines the basic capabilities Inter- 
Voice calls or facsimile transmissions, which are not 45 net telephony software must support, and it specifies 
distinguished from voice calls by the phone network, must requirements for call control, audio, and video compression 
first be converted from analog signals into digital form. This technologies. 

conversion is performed by a codec (compression/ The H.323 standard is directed to the types of data streams 

decompression), which can be implemented either in soft- required for Internet telephony. All telephone software must 

ware or special-purpose hardware. Digitally encoding of 50 support specified audio (such as speech) and call-control 

voice calls is also done in the PSTN for interoffice trans- signals that permit telephones to find each other, determine 

mission by systems such as private branch exchanges each other's characteristics, and then monitor call status. 

(PBXs). However, the codecs used for VoIP use bandwidth This standard also specifies lowest-common denominator 

more efficiently than the those used in the PSTN, carrying compression protocols, such as 0.711 (audio compression 

voice in as little as 5 Kbps compared with the 64 Kbps 55 over 64-Kbps data path), G.723 and G.729 (audio compres- 

needed by the phone network. sion over an analog modem). H.323 also specifies the 

Once digitized, the encoded voice data is then wrapped functions to be performed by a network control server, 

within IP packets, using a Real-Time Transport Protocol known as the "gatekeeper." 

(RTP), which runs over UDR (UDP is the connectionless Currently, H.323 requires that Internet telephones also 

transport protocol in the TCP/IP protocol suite; it serves as 60 adhere to H.245, the ITU-T standard for telephony control 

the counterpart to TCP, which is the connection-oriented functions. H.245, along with the associated H.225.0 and 

protocol.) IP packets then are carried over a TCP/IP network. Q.931 standards, defines how a phone should connect to 

Call setup and control-type features for voice, modem, another phone over the Internet, start a conversation, deter- 

facsimile, video and data systems are, based on the H.323 mine the capabilities of the receiving phone, and hang up a 

Internet telephony standard (described below). 65 call. During call initiation, the devices use H.245 to deter- 

It is desirable to incorporate some form of quality of mine proper compression protocols and also whether the 

service (QoS) features that can give a higher priority to phones support full-duplex or half-duplex transmission. 
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They also agree on what resolution is recommended for (TE^-TE^) are programmable to provide diagnostic infor- 

video, which encryption capabilities are supported or mation over the Internet 110 to each other or to the DS 108. 

desired^ and the maximum "jitter'' (variation in delivery time The diagnostics are dependent on the type of connection, 

for data packets) that will be allowed before the session is which can be either an Internet telephone voice call, transfer 

terminated. 5 of video, facsimile, data, or control information. Known 

JJ1 .-iJ methods and protocols to communicate voice, modem, 

Other Internet standards are under development, mclud- r • i -j ^ j . j . i • r 

„ • T n . 1 /oit^\ J .1- o- 1 facsimile, video, data and control information over the 

mg the Session ImUation Protocol (S^ Simple ^^^j^ ^ ^ 

Gateway Control Protocol (SGCP). SIP, a signahng protoco ^j^^^^j telephony andVoIP 

tor Internet conrcrencmg and telephony, handles basic call • r j j • 

t- ^- ,1 j - I. 11 in Diagnostic information provided in this matter can give a 

setup functions as weU as enhanced services such as call * i j • • ^ ^ j • r i lT 

r J* J J i_ -1 11 jj network admimstrator advance warning 01 client problems, 

lorwarding. SIP addresses users by an e-mail-like address j/ i.- . • i j * _c n 

J ^ r*i- c** jfT* * -1 and/or historical data performance profiles. This can allow 

and reuses some of the mfrastructure used for Internet e-mail ^ i j • • ^ ^ * • ^ w l 

J t_ T>wvTo /rx • VT o . -1 the network admimstrator to mitiate solutions perhaps even 

delivery such as DNS MX (Domain Name System mail . - i- r *u a 

r J. X , r ...J , JJ f ^ 10 advance of the client s recognition of the problem. A 

forwarding) records. In addition to its own address format, . c c a- ^ - % L -j j 

oTn u ji TT '^^^ J J *i u I. / 1^ plethora of uses for diagnostic information can be provided 

SIP can handle H.323 addresses or telephone numbers (as 35 "& _ j . 

defined by the E.164 standard). SGCP is part of a VoIP '° ^'^^ "^^"TJ" 

architecture that distributes the voice-to-IP gateway func "'^'"V""- .'^f/'y °^ . diagnosUc infonnation 

L * * 1 * I.- 1- _r : 1 according to the present mvention are descnbed below by 

tions between the actual gateways, which perform transla- ^ i j^i -**- 

u * • -1 /m 1 ; J way of example and not limitation, 

tion between voice signals and IP packets, and a server . . r t^t^ ^ . 

known as the "call agent," which handles complex signaling ^ . t^™'"^ endpoints 102, 104-106 of FIG. 1 can be 

protocols such as SS7. SGCP handles the communication implemented m a vanety of ways. FIG. 2 lUustrates various 

between the call agent and the gateways. SGCP primarily is 'yP^* endpomts m a system sunilar to that 

designed to serve as a simple "remote control" protocol that f P,f '° ™- ^ commumcatmg diagnosUcs or other 

the call agent uses to program gateways according to feedback concerning Internet connections according to the 

instructions received through signaling protocols such as 25 present mvention. In Uie smiplest form a terminal endpomt 

H 323 or SIP ^ ^ communication device, such as a standard telephone 

with an IP gateway, which is illustrated at 202. Alternatively, 

C. Real-Time Transport Protocol and Real-Time a terminal end pomt can comprise an Internet phone, as 

Control Protocol illustrated at 204. Moreover, the Internet phone 204 can 

30 include the functionality of a diagnostic supervisor. Another 

The Real-Time Transport Protocol (RTP) handles end-to- ^^^^^^^ ^ terminal endpoint is a personal computer 206, 

end, real-time delivery of data such as video and voice. RTP ^^ich can also function as a diagnostic supervisor. Other 

transports data over the UDP and does not guarantee in-time examples of terminal endpoints include servers and clients, 

delivery, order of delivery, or even debvery at all. RTP ^ ^^^^ j^^ninal endpoint is illustrated in 208, which can 

provides fonctionality that is required for real-time multi- ^^^^ ^ diagnostic supervisor, FIG. 2 also illustrates 

media traffic, including content identification timing ^ ^j^^^j ^^^^^^^ ^^^^point 210. The client/TE 210 is effec- 

reconstnicuon loss detection, and secunty. With RTP, data ^^^^ ^ ^^^^ ^ ^le of switching between a plurality of 

can be delivered to one or more destmaUons, and limits any communication devices such as phones 212, 214 through 

delay, vanation. Although RTP can take advantage of 2I6. Alternatively, a pei^nal computer communication 

resource reservation protocols such as RSW, ^^^unumcat- ^^^^^^ ^ ^^^^ computer communication device also 

mg dynamically to allocate appropnate bandwidth, but RTP functioning as a diagnostic supervisor can be connected to 

itself does not provide for guaranteed bandwidth or other the node and be part of the clientyTE210. Such a PC/DS is 

QoS features. illustrated at 218. A server 208 keeps all the general info 

Time stamps and header information are provided by RTP, about a network's configuration. It is also considered a 

which distinguish whether an IP packet is data or voice, master of the network, unless it's functions are distributed, 

allowing prioritization of voice packets. RSVP allows net- ^jq 3 illustrates a distributed diagnostics management 

working devices to reserve bandwidth for carrying unbroken system of servers (302, 304-306) and clients (308, 

multimedia data streams. 310-312), which commuoicate via the Internet 110. IP 

A companion protocol to RTP is Real-Time Control connections between servers and clients, between plural 

Protocol (RTCP), which analyzes network conditions. RTCP 50 servers, or between plural clients can also be routed via the 

provides feedback to RTP data sources and recipients in a PSTM 314. In this embodiment, the diagnostic supervisory 

periodic transmission fashion. RTCP permits adjustment to functions can be distributed or can be redundant between 

changing network loads by reporting to senders and receiv- multiple servers, such as server 1, or server 2 through server 

ers various types of variations in network performance. n. The exemplary functions to be performed by a diagnostic 

55 supervisor will now be described in connection with FIG. 4. 
FIG. 4 illustrates an exemplary architecture for a Diag- 
nostic Supervisor 108, according to the present invention. 

A system 100 for communicating diagnostics or other The Diagnostic Supervisor 108 includes a Configuration 

feedback concerning Internet connections firom one or more Manager 402, a Report Manager 404, a real-time response 

terminal endpoints TEj-TE^ (102, 104 through 106, 60 manager 406, and an Input/Output (I/O) Manager 408. 

respectively) to a Diagnostic Supervisor (DS) 108 as illus- These four managers are interconnected by a bus system 

trated in FIG. 1. The connections between the TEs and the 410, which permits the four managers to communicate 

DS are performed using Internet protocol, as shown gener- directly with each other in a flexible manner. Alternatively, 

ally at Internet cloud 110. According to the present direct wiring or busing between each of the four managers 

invention, the Internet cloud 110 may be the public Internet 65 can be provided, as would be apparent to a person skilled in 

or private internet. As will be described in detail below, the relevant art. The Diagnostic Supervisor 108 can also 

according to the present invention the terminal endpoints include an internal or external communication controller 



II. SYSTEM DESCRIPTION OF THE PRESENT 
INVENTION 
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412. The communication controller 412 handles call func- 
tions such as call control and VoIP management. The com- 
munication controller 412 can be directly coupled to the bus 
system 410, and thus can be considered an integral part of 
the Diagnostic Supervisor 108. Alternatively, the communi- 
cation controller 412 can be external to the Diagnostic 
Supervisor 108 and be coupled to the Diagnostic Supervisor 
108 through the I/O manager 408. Managers 402, 404, 406 
and communication controller 412 can communicate via the 
I/O manger 408 with the Internet 110, and the PSTN 314. 
Alternate implementations can combine one or more of the 
managers 40^, 404, 406, 408 into one entity. 

The Configuration Manager 402 of the Diagnostic Super- 
visor 108 permits a user or network administrator to con- 
figure the diagnostic information to be provided by terminal 
endpoints before, during or after an Internet connection 
(e.g., the VoIP call). As will be described in detail below, the 
Configuration Manager 402 is programmable to provide 
diagnostic control messages (DCMs) to TEs in order to 
configure the terminal endpoints (TEs) to provide the 
desired diagnostic information. 

The network administrator can program the Configuration 
Manager 402 to generate DCMs in a variety of manners. For 
example, the network administrator can program the Con- 
figuration Manager 402 by a personal computer 414 via the 
Diagnostic Supervisor 108 via the I/O manager 408. 
Alternatively, the network administrator can program DCMs 
using the Configuration Manager 402 remotely over an 
Internet connection, via a telephone link and the PSTN 314, 
or by a direct connection, such as a serial, parallel, or optical 
port directly to the Diagnostic Supervisor 108. Such direct 
(hardwired or wireless) connections are not illustrated in 
FIG. 4. 

The Report Manager 404 receives Diagnostic Messages 
(DMs) from terminal endpoints configured by DCMs to 
relay diagnostic information or "events" to the DS 108. DMs 
arc received by the Report Manager 404 via the I/O manager 
408 and bus network 410. The DMs can be transmitted from 
TEs via the Internet 110 or the PSTN 314. In an alternative 
embodiment of the present invention in which the diagnostic 
supervisor includes a communication controller 412, the 
Report Manager 404 can also receive DMs firom the com- 
munication controller 412. In this alternative embodiment, 
the communication controller 412 is the equivalent of a 
terminal endpoint and thus is also configured by DCMs from 
the Configuration Manager 402 to relay DMs to the Report 
Manager 404, Thus, the Diagnostic Supervisor 108 receives 
DMs reflecting its own events. 

The Report Manager 404 is programmable to provide 
reports for the network administrator in a human readable 



10 



15 



20 



25 



35 



45 



format. For example, reports can be provided by the Report 
Manager 404 in text form, graphic user interface form via 
the PC 414, as voice messages, or simply as printouts via a 
printer 416. Based on the below discussion of diagnostic 
configuration messages and diagnostic messages, the pro- 
gramming of Report Manager 404 to produce reports for the 
network administrator would be apparent to a person skilled 
in the relevant art. Moreover, the Report Manager 404 can 
be programmed to provide reports to the network 
administrator, other user or any network device over the 
Internet 110 or PSTN 314 via the I/O manager 408 and bus 
network 410. 

The Real-Time Response Manager (RTRM) 406 also 
receives DMs and acts in real-time to perform any necessary 
response to events. In addition to the varioxis responses 
provided by the RTRM 406 as described below, it can 
generate external warnings using devices such as an external 
alarm 418, pager device 420, or the like, as would be 
apparent to a person skilled in the relevant art. 

^^^Ssillustrates an exemplary architecture for the Con- 
figuration Manager 402 according to an embodiment of the 
present invention. The Configuration Manager 402 includes 
a Diagnostic Configuration Message (DCM) Generator 502, 
a DCM Transceiver Unit 504 and ^a^^ figuflEionFdatalgise 
^56:'The DCM Generator 502 permits a network adminis- 
trator to create DCMs in order to configure TEs. 

, An example of a DCM is an information element (IE) 
having a format illustrated below in Table 1. Column (a) of 
Table 1 is the Field Number that lists the sequential number 
of information fields in the IE. Column (b) is the Field 
Length (octet) that gives the length in eight bit octets of each 
information field. Column (c) is the Information Field Name 
that lists the name of each information field used in the IE. 
Column (d) is the Information Field Description that 
describes the function, format and purpose of each infor- 
mation field in the IE. The last column (e) is the Format and 
Value that defines the value or data format used in each 
information field. Unless noted otherwise in the field 
description, the data format used in each information field is 
an unsigned hexadecimal value. If the information field is 
composed of more than one octet, the first octet is the most 
significant byte and the last octet is the least significant byte. 
The diagnostic parameters of the DCM for QoS, for 
example, are delivered in a Q.931/H.225.0 "like" block 
messages. The DMs described below are also delivered 
through Q.931/H.225.0 "like" block messages. The DM 
message formats are described below in connection with 
Table 2. 



TABLE 1 









DCM m Format 






Field 






Format 


Field 


Length Information 




and 


Num. 


(octet) 


Field Name 


Information Field Description 


\^lue 


(a) 


(b) 


(c) 


(d) 




1 


1 


QOS_TRAP_n 


B This is the infonnaUon element identifier field for the 


QxXX 






(1) 


DCM (QOS_DIAGNOTICE_IE). This is a fixed length 










information element 




2 


2 


[E_Length 


This field defines the length of the "contents" of the 


Hex 








information element 




3 


1 


MODE 


This field is bit mapped. This first bit turns on and off auto 


Hex 








reporting. The second bit provides for a one time report in 
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TABLE 1 -continued 







DCM IE Format 






Field 




Formal 


Reld 


Length Information 




and 


Num. 


(octet) Field Name 


Information Field Description 




(a) 


(b) (c) 


(d) 





15 
16 



18 



19 



2 SOURCE 

1 DESnN>«nON 



6 


2 


DESTINAnON 






1_TSAP 


7 


2 


DESTINATION 






2_TSAP 


8 


1 


Losr_ 






PACKETS^ 






TRAP 


9 


2 


LO£rr„ 






PACKETS,, 






TIME 


10 


1 


SILENCE_ 






PACKETS_ 






TRAP 


11 


2 


SILENCE_ 






PACKETS_ 






TIME 


12 


1 


NON_ 



SILENCE_ 
PACKETS 



NON_ 
SILENCE_ 
PACKETS^ 
TIME 

AVG_JnTER_ 
TRAP 



AVG_JnTER_ 
TIMER 
INVAUD_ 
HEADER 



INVAUD_ 
HEADER_ 
TIMER 

IDLE_PACKET 
_TRAP 



2 IDUE_PACKFr 
_TIMER 



response to each QOS_TRAP_IE received. 
1st Bit: "1" Auto Reporting on 

"0" Auto Reporting o£F 
2nd Bit: "1" One time response on 

"0" One time response off 
This field provides the address of the TE that is being Hex 
configured for auto-reporting of diagnostic information. 
This field tells the TE were to send the diagnostic reports. Hex 
The last type octets define the IP address, The first byte is bit 
mapped. When each bit is set to the diagnostic report is 
send to the location defined as follows: 
1st bit Communications controller 

2nd bit far end party 

3rd bit far end party and alt conference partners 

4th bit Diagnostic TSAP 1 defined below 

5th bit Diagnostic TSAP 2 defined below 

This field defines the IP address and port where the diagnostic Hex 

messages are sent 

This field defines the IP address and port where the diagnostic Hex 
messages are sent. 

ThLs field defines the value at which the percentage of lost Hex 
packets will cause a diagnostic report to be sent. The period 
of time over which the percentage of lost packets is calculated 
is defined below. 

This field defines the time period in seconds over which the Hex 
pciccntage of lost packet is calculated. During a call, the 
percentage of lost packet is calculated over consecutive time 
intervals until the completion of the call. 

This field defines the value at which the percentage of silence Hex 
packets will cause a diagnostic report to be sent. The period 
of time over which the percentage of lost packets is calculated 
is defined below. 

Note: This trap can be used to perform disconnect supervision 
when an IPA'bice gateway is bridged to a PSTN station, 
tiunk, or service that does not provide disconnect supervision. 
This field defines the time period in seconds over which the Hex 
percentage of silence packets is calculated. During a call, the 
percentage of silence packets is calculated over consecutive 
time intervals until the completion of the call. 
This field defines the value at which the percentage of non- Hex 
silence packets will cause a diagnostic report to be sent The 
period of time over which the percentage of lost packets is 
calculated is defined below. 

Note: This trap can be used to perform answer detection when 

a IP/VOICE gateway is connected to a PSTN station or trunk 

or service that does not support answer detection. 

This field defines the time period in seconds over which the Hex 

percentage of non-silence packets is calculated. During a call, 

the percentage silence packets is calculated over consecutive 

dme intervals until the completion of the call. 

This field defines the value at which the average packet jitter Hex 

will cause a diagnostic report to be sent The period of time 

over which the average packet jitter is calculated is defined 

below. 

TTiis field defines the time in units of seconds over which the Hex 
jitter average is calculated. 

TTiis field defines the value at which the number of packets Hex 
with invalids will cause headers a diagnostic message to be 
sent by the TB. The period of time over which the total 
nun^er of invalid headers is counted is defined below. 
This field defines the time in units of seconds over which the Hex 
invalid header count is maintained 

Tliis field defines the value at which the percentage of idle Hex 
packets will cause a diagnostic report to be sent The period 
of time over which the percentage of idle packets is calculated 
is defined below. 

This field defines the time period in seconds over which the Hex 
percentage of idle packets is calculated. During a call, the 
percentage of sUence packets is calculated over consecutive 
time intervals until the completion of the call. 
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TABLE 1 -continued 









DCM IE Format 






Field 






Format 


Field 


Length Information 




and 


Num. 


(octet) Field Name 


Information Field Description 


V^lue 


(a) 


(b) 


(c) 






20 


1 


REPLAY_ 


This n.eld defines the value at which the percentage of replay 


Hex 






PACKET_ 


packets will cause a diagnostic report to be sent The period 








TRAP 


of time over which the percentage of idle packets is calculated 








is defined below. 




21 


2 


REPLAY_ 


This field defines the time period in seconds over which the 


Hex 






PACKET^ 


percentage of idle packets is calculated. During a call, the 








TIMER 


percentage of silence packets is calculated over consecutive 










time intervals until the completion of the call. 




22 


2 


MAX_jnTER_ 


This field defines the value at which the peak packet jitter will Hex 






TRAP 


cause a diagnostic rqjort to be sent. The period of time over 










which the peak packet jitter is calculated is defined below. 




23 


2 


MAX_JnTER_ 


This field defines the time in units of seconds over which the 


Hex 






TIMER 


maximum jitter is calculated. 





The DCM generator 502 transmits DCMs via the DCM 
transceiver unit 504. The DCMs are sent to one or more TEs 
and are stacked inside the use-to-user information element 
(UUIE) attached to the Q.931/H.225.0 setup message or 25 
alerting message. The purpose of the UUIE is to convey 
information between Q. 93 1/H. 225.0 users (in this case the 
Diagnostic Supervisor 108 and TEs). The DCM conveyed in 
the UUIE is not interpreted by the network, but rather is 
carried transparently and delivered to the remote TEs. The 30 
specific coding of a UUIE is fully described in section 4.5.30 
of the International Telecommunication Union (ITU) Tele- 
communication Standardization Sector (ITU-T) Recom- 
mendation Q.931, which was approved by the World Tele- 
communication Standardization Conference (WTSC) in 35 
Helsinki on Mar 1-12, 1993. The implementation details of 
transporting information via the UUIE therefore would be 
apparent to a person skilled in the relevant art. 

Hie DCMs configure the TEs to provide DMs back to the 
Diagnostic Supervisor 108. This configuration permits the 40 
TEs to provide a variety of diagnostic parameters that give 
real time information about the quality of the inbound and 
outbound voice, modem, facsimile, video or data streams for 
a given IP connection. This diagnostic information can be 
polled (i.e., requested) by the communications controller 45 
412 of a combined DS/TE or from any TE participating in 
an IP connection. In addition to polling, the diagnostics can 
be automatically delivered to the DS or any participating 
DS/TE or TE. This automatic delivery of diagnostics is 
provided based on parameters contained in the DCMs which 50 
are generated by the Configuration Manager 402. 

The configuration database 506 can be used by the DCM 
generator 502 or network administrator to store various 
different of configurations. For example, configuration data- 
base 506 can store logs of transmitted DCMs, including, for 55 
example, a copy of the DCMs, a list of the target TEs and 
time and date information. The configuration database 506 
can also store DCM acknowledgments received by the DCM 
Transceiver 504 from recipient TEs or from the communi- 
cation controller 412. 60 

Turning again to Table 1, various features of the DCM 
information element (IE) format will be explained. The 
DCM, can be in the format of a Q.931/H.225.0 block 
message. The first field in the DCM is the information 
element identifier. Appended to the information element 65 
identifier are information elements labeled field numbers 
2-23. Field number 2 represents the length of the DCM 



information element. Field number 3 is the Mode Informa- 
tion field, which is a bit mapped byte. One bit turns off auto 
reporting. The second bit provides for a one time report as 
a compelled response to DCM IE. Field number 4 is the 
Source Information field, which provides the address of the 
IP-Board of the TE that is being configured for auto- 
reporting of diagnostic information. 

Field number 5 is the Destination Information field, which 
tells the IP-Board where to send the DM. For example, when 
the first bit it set to "1" the DM sent to the local commu- 
nication controller 412 (where the IP-Board would typically 
reside) and the Report Manager 404. If the second bit is set 
to "1** the DM is sent to the far end party. Setting bits 3 to 
5 yields the functionality listed in Table 2, field number 5, 
column (d). 

Remaining field numbers 8-23 represent example param- 
eters that a TE can be configured to trap. In other words, a 
TE is configured by the DCM to keep track of certain 
parameters and relay them according to the configuration 
specified by the DCM in field numbers 5-23. For example, 
field number 8 lists the LOST_PACKETS_TRAP informa- 
tion field. This field defines the value at which the percent- 
age of lost packets wlL cause a DM to be sent. The period 
of lime over which the percentage of lost packets is calcu- 
lated is defined in field number 9, which is the LOST_ 
PACKETS_TIME information field. 

Similarly, a silent packet trap is defined by fields 10 and 
11 and a non-silent packets trap is defined in field numbers 
12-13. An average jitter trap is defined in field numbers 14 
and 15. An invaUd header trap is defined in field numbers 16 
and 17. An IDLE_PACKET_TRAP is defined in field 
numbers 18 and 19. A REPLAY_PACKET_TRAP is 
defined in fields 20-21 and a maximum jitter trap is defined 
in field numbers 22 and 23. 

Once configured, a TE is then capable of responding to 
DCMs by transmitting DMs to the destination or destina- 
tions specified in field numbers 5-7 of the IE corresponding 
to the DCM as described above. Table 2 lists an exemplary 
information element format for a Diagnostic Messages 
(DM) according to the present invention. As with DCMs, 
DMs are defined in a set of Q.931/H.225.0 *'like" informa- 
tion elements. The DMIE can be stacked inside the UUIE 
when transmitted over a H.323 network. Column (a) of 
Table 2 lists the sequential number of information fields in 
the IE. Column (b) lists the length in eight bit octets of each 
information field. Column (c) lists the name of each infor- 
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mation field used in the IE. Column (d) describes the 
function, format and purpose of each information field in the 
IE. The last column (e) defines the value or data format used 
in each information field. Unless noted otherwise in the field 
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description, the data format used in each information field is 
an unassigned hexadecimal value. If the information field is 
composed of more than one octet, the first octet is the most 
significant byte and the last octet is the least significant byte. 



TABLE 2 



DM IE Format 



Field 

Field Length Information 
Num. (octet) Field Name 
(a) (b) (c) 



Information Field Description 
(d) 



Format 

and 

\felue 



QOS_J)IAG 
NOSmCJE 
(1) 

IE_Leiigth 
Call 

Reference 



Conference 
ID 

Source 



1 Media_ 
Type 



This is the information element identifier field for the 
DM (QOS_DIAGNOSTICE_IE). This is a fixed 
length information element. 

This octet defines the length of the "content" of the 
information element 

This is the call reference field. This 2 octet field 
identifies the call from which the diagnostic 
information is provided. For multiparty conferences, 
each party may have a different call reference value. 
For multi-party conference calls j this 2 octet field 
identifies the conference number. 
This field identifies the IP address of the TE that is 
sending the QOS diagnostic information element 
This field may be set to 0x0000 when the IE is being 
sent over commionications controller and represent 
the local TE. This field may be set to OxFFFF when 
the IE is being sent over the communications 
controller and the represents the far-end party in a 
two party call. 

This field defines Uie media type being processed by 
the TE that sends the diagnostic message. The values 
for this field are defined as follows: 
Value Media 



OxXX 



Hex 



Hex 



Hex 



Hex 



DIAG_TIME 
PERIOD 



TRAP_ 
ACnVEl 



Hex 



1 Voice 

1 FAX-Relay 

2 Modem 

3 Video 

4 Data 

This field defines the period of time in seconds over 
which diagnostic information is collected. If the 
value is OxFFFF, diagnostic information is collected 
over the entire length of the call. 

This is a bit mapped octet were a bit corresponds to a Hex 
set of trap conditions, [f a trap condition is satisfied, 
the bit is set to "1", The trap conditions are 
programmed for each TE through the IE summarized 
in the next table. If no trap condition is met, the bit is 
set to "0". The bit map is summarized below: 
BET Trap Description 



1st 
2nd 
3Td 
4th 
5th 
<ith 
7th 
8th 



Lost packet trap 
Silence packet trap 
Non silence packet trap 
Average jitter trap 
Invalid header trap 
Idle packet trap 
Replay packet trap 
Maximum jitter trap 



9 


1 


TRAP_ 


This field is reserved for future trap diagnostics. 


Hex 






ACTIVE2 




10 


2 


RX_PACKE 


This field defines die average packet length of 


Hex 






T_ 


received packets. 








SIZE 






11 


4 


RX_PACKE 


This field defines the total number of received 


Hex 






TS 


packets. 




12 


2 


LOST_ 


This counter keeps track of the number of packets not 


Hex 






PACKETS 


received. 




13 


2 


SILENCE_ 


This counter keeps track of the number of packets 


Hex 






PACKETS 


that contain silence information descriptors (SID). 




14 


2 


IDLE_ 


When an inbound pack^ is lost, one method for 


Hex 






PACKETS 


filling in the lost packet is to create a '*pink" noise 





packet "niifl pink noise packet is referred to as an 
IDLE packet TTiis counter keeps track of the number 
of times a lost packet is replaced with a pink noise 
packet 
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DM IE Format 






Field 






Format 


Field 


Length Information 




and 




(octet) 


Field Name 


Information Field Description 


Value 




iP) 




(d) 


(0 


15 


2 


REPLAYED 


When an inbound packet Ls lost, one method for 


Hex 








filling in the lost packet is to replay the previous 








PACKETS 


packet. This counter keeps track of the number of 










times a packet is replayed to fill in a lost packet. 




16 


2 


DROPPED_ 


Some packets arc received but they come too late to fit Hex 






PACKETS 


into the jitter buffer. This counter keeps track of the 










number of packets that come too late to fit into the 










jitter buffer. 




17 


2 


PLAYOUT_ 


This parameter provides the average delay in the 


Hex 






DELAY 


voice play out unit FIFO in ms. 




18 


2 


MIN_ 


This parameter gives the minimum packet 


Hex 






JITTER 


interanival time in ms. 




19 


2 




This parameter gives the maximum padcet 


Hex 






JITTER 


interanival time in ms. 




20 


2 


INVALID^ 


This parameter provides the number of incoming 


Hex 






HEADER 


packets with invalid headers. 




21 


2 


MICRO_ 


This parameter provides the number of transmit voice 


Hex 






OVERFLOW 


packets dropped due to buffer overflow. 
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TABLE 2-continued 



As with the DCM information element format as dis- 
cussed above in connection with Table 1, the DM element 
format, of Table 2 is similar to a Q.931/H.255.0 block 
message. The first component in field number 1 is the 
information element Identifier field for the diagnostic mes- 30 
sage IE. Field number 2 is the Length of the DM information 
element in octets. Field number 3 is the Call Reference 
information field, which is a two octet field identifying the 
call 0P connection) fi"om which the diagnostic information 
is provided. For multi-party conferences, each party can 35 
have a dififerent call reference value. Field number 4 is the 
Conference ID information field, which identifies the con- 
ference number for multi-party IP connections. Field num- 
ber 5 is the Source information field. This field identifies the 
IP address of the TE that is sending the QoS diagnostic 
information element (i.e., the TE transmitting the DM). 

A Media Type information field is illustrated in field 
number 6 of Table 2. This field determines the type of media 
being processed by the TE that sends the DM. The values for 
this field are specified in field 6 of Table 2 according to 
whether the media is voice, modem, facsimile, video or data. 

Field number 7 is the diagnostic time period (DIAG_ 
TIME Jeriod) of the trap condition that caused the sending 
of the DM. If the value is xFFFF, for example, diagnostic 
information was collected over the entire length of the IP 50 
connection. Field number 8 is the Trap Active 1 information 
field. This is a bit mapped octet in which each bit corre- 
sponds to a condition. If a trap condition is satisfied, the bit 
is set to "1". The trap conditions are programmed for each 
TE through the information element summarized in the 55 
"BIT" table listed in the information field description of field 
number 8 in Table 2. The trap descriptions for the Trap 
Active 1 information field includes: loss packets, silent 
packets, non-silence packets, average jitter, invalid header, 
idle packets, replay packets, and maximum jitter. 

Field number 9 is the Trap Active 2 information field, 
which is reserved for future Trap diagnostics. Fields 10 
through 21 corresponds to various QoS parameters. 

FIG. 6 illustrates an exemplary architecture for the Report 
Manager (RM) 404 according to the present invention. 65 
Report Manager 404 includes a diagnostic messages 
receiver 602, a Report Generator 604 and a IRM database 



608. The DM receiver 602 receives DMs from TEs or a 
communications controller, such as communication control- 
ler 412. DMs accepted by the DM Receiver 602 are stored 
in the RM database 608. The Report Generator 604 retrieves 
received DMs from the RM database 608 and formats 
reports for a user or the network administrator in a human 
readable fashion. The Report Generator 604 is program- 
mable to facilitate many report formats. Reports can be 
generated by Report Generator 604 and presented to the 
network administrator using the PC 414 or a printer 416. 
Alternatively, diagnostic message reports can be accessed 
via the Internet 110 or PSTN 314 via I/O manager 408 and 
the bus 410. Reports can be generated on a TE basis, a client 
basis, a server basis or on a partition basis if the commu- 
nications network supported by the DS 108 is partitioned. 
Reports can be provided by the Report Manager 404 on a 
automatic or on a query basis. 

FIG. 7 illustrates an exemplary architecture for the real- 
time response manager (RTRM) 406 according to the 
present invention. The RTRM 406 includes a connection 
Rerouting Controller 702, an Alarm Controller 704, a 
Resource Reallocation Controller 708 and a Bus System 
710. Bus System 710 permits elements 702, 704 and 708 to 
communicate with each other, as well as communicate with 
elements external to the RTRM 406 via the bus 410. 

A feature of the RTRM 406 according to the present 
invention is to respond to diagnostic messages by rerouting 
Internet connections to the PSTN 314. The decision to 
reroute connections (e.g., VoIP calls) can be made by the 
RTRM 406, or by TEs comprising distributed call routing 
functionality as described in detail below in connection with 
FIG. 9. Parameters that can cause rerouting of a connection 
(including but are not limited to voice, modem, facsimile, 
data or video connections) are: prioritization, parameter 
limit concerns, malfunctioning codecs, or the like. 

The Alarm Controller 704 provides external alarming of 
a user via the alantn 418 for example, or notifications to other 
network devices such as TEs, distributed DSs, servers, 
clients, PCs, IP-phones, or the like. 

The Resource Reallocation Controller 708 also responds 
to diagnostic information provided by DMs. The Resource 
Reallocation Controller 708 can adjust parameter thresholds 
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by passing necessary adjustment inform ation to the Con- 
figuration Manager 402, which in turn provides DCMs to 
TEs to thereby modify the trapping of various parameters 
based on the new threshold value(s). Controller 708 is 
capable of creating new diagnostics or disabling existing 5 
diagnostics monitored by the TEs. Controller 708 also 
provides transient filtering of diagnostic information to 
adjust thresholds, create new diagnostics or disable existing 
diagnostics. Moreover, the controller 708 can simply disable 
or enable nctworic resources or devices such as TEs, or the lO 
like. 

FIG. 8 illustrates an exemplary architecture for a terminal 
endpoint (TE) 800 according to the present invention. TE 
800 includes a Diagnostics Controller 802, a Terminal 
Communications Controller 804, a DCM Transceiver 806, a 15 
DM Transceiver 808, and an I/O Controller 810. 

The Diagnostics Controller 802 receives and transmits 
DCMs via DCM Transceiver 806. The Diagnostics Control- 
ler 802 is configured using DCMs received from one or more 
Diagnostic Supervisor 108. The Diagnostics Controller 802 
monitors IP and PSTN connections by communicating with 
the Terminal Communications Controller 804. The Diag- 
nostics Controller 802 receives diagnostic information 
regarding IP connections from a network manager module 
(not shown), such as that provided by Telogy Networks and 
described by GOLDEN GATEWAY® Interface, User Guide 
Version 2.5 for Release 5.1 (Telogy Networks, Germantown, 
Md.). 

The Diagnostics Controller 802 formats DMs to be trans- 
mitted to the Diagnostic Supervisor 108 according to the 
information element format described above in connection 
with Table 2. The setting of parameters and transmission of 
DMs is determined by the Diagnostics Controller 802 
according to DCMs received by the DS 108, according to the 
information element format described above in connection 
with Table 1. The DM Transceiver 808 transfers DMs 
prepared by Diagnostics Controller 802 to one or more DSs 
108 or other TEs, Additionally, DM Transceiver 808 
receives DMs from other TEs in the event that the TE 800 
includes distributed DS functionality or can otherwise act on 
DM information from a far end IF or PSTN connection. 
DCMs and DMs are transmitted and received via the I/O 
Controller 810 to/from the Internet 110 or PSTN 314. 

The Terminal Communications Controller 804 of the 45 
terminal end point 800 performs voice, modem, facsimile, 
video and data connections with other TEs connected to 
either the Internet 110 or PSTN 314, as would be apparent 
to a person skilled in the relevant art. An example commu- 
nication protocol stack used by the Terminal Communica- 
tion Controller 804 is the H,323 Protocol Stack manufac- 
tured by RAD Vision Inc. (Mahwah, NJ.). 

As discussed above, providing diagnostic information 
concerning TEs IP and/or PSTN connections is very useful. 
For example, an Internet connection, such as a VoIP call, can 55 
be rerouted from the Internet to the PSTN for a variety of 
reasons, some of which are triggered by diagnostic infor- 
mation. FIGS. 9A-9C illustrate exemplary flow diagrams of 
IP connection routing to the PSTN according to the present 
invention. The progress of connections between communi- 
cation devices illustrated in these diagrams advances in time 
from top to bottom, as shown at the arrows labeled "t". 

FIG. 9 A illustrates rerouting of an IP connection between 
terminal endpoints TEl and TE2, The IP connection, such as 
a VoIP call, between TEl and TE2 is shown generally at 902. 65 
During their IP connection either TEl and/or TE2 will send 
Diagnostic Messages (DM) to the Diagnostic Supervisor 
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(DS) as shown generally at 904. Diagnostic information can 
also be sent before and after the connection is estabhshed. In 
this embodiment, the DS will evaluate the diagnostic infor- 
mation provided by the DMs and determine whether or not 
to reroute the IP cormcction between TEl and TE2 from the 
Internet to the PSTN. If the DS determines that rerouting is 
necessary, the DS will send an alert to both TEs, as shown 
generally at 906. Beeps or other notification can be provided 
to the user to audibly alert that the connection will be 
rerouted to the PSTN. The communications controllers of 
both TEs will then handle rerouting of the call from the 
Internet to the PSTN, as shown generally at 908. Once 
rerouting is completed, the TEs will transmit reroute 
acknowledge signals (ACK) or not acknowledge (NACK) 
signals back to the Diagnostic Supervisor 168 indicating 
whether or not the rerouting to the PSTN was successful, as 
shown generally at 910. 

FIG. 9B illustrates an alternative embodiment of the 
present invention for rerouting IP connections to the PSTN. 
In this embodiment, TEl also has diagnostic supervision 
functionality. An IP connection over the Internet between 
DS/TEl and TE2 is shown generally at 912. TE2 transmits 
DMs to DS/TE2 during the IP connection, as shown gener- 
ally at 914. DS\TE1 also will internally monitor diagnostic 
information at its end of the IP connection, as shown 
generally at 916. If DS\TE1 determines that rerouting is 
necessary it will send an alert to TE2, as shown generally at 
918. The IP connection will then be rerouted to the PSTN as 
shown generally at 920, An ACK or NACK signal will be 
sent by TE2 to verify whether or not the rerouting was 
effective on its end of the connection, as shown generally at 
922. 

FIG. 9C shows yet another alternative embodiment for 
rerouting IP coimections to the PSTN. In this embodiment, 
both TEl and TE2 have diagnostic supervision capabilities. 
An IP connection between DS\TE1 and DS\TE2 is shown 
generally at 924. The two DS/TEs transmit DMs to each 
other during the IP connection, as shown generally at 926. 
An alert will be sent by DS\TE1 or DS\TE2 in the event that 
a determination to reroute tire IP connection has been made, 
as shown generally at 928. Rerouting of the connection to 
the PSTN and acknowledgment are shown at 930 and 932, 
respectfully. In this embodiment a user can initiate rerouting 
to switch to the PSTN for any reason. 

FIG, 10 illustrates an exemplary flow diagram for dis- 
connect supervision and answer detection of IP connections 
according to embodiments of the present invention. As 
would be apparent to those skilled in the relevant art, 
disconnect supervision and answer detection are useftil 
functions in communications systems. The adaption of dis- 
connect supervision and answer detection in an IP connec- 
tion environment will provide these features where they 
otherwise are not supported. 

VoIP wrappers provide headers that specify whether the 
data portion of the packet is empty or not. If the data portion 
is empty, the packet is considered a silent packet. Non-silent 
packets followed by many silent packets may indicate the 
call has effectively terminated, perhaps abnormally. Thus, 
detection of silent packets can indicate that the call should 
be automatically disconnected. Many silent packets fol- 
lowed by non-silent packets can indicate the call has been 
answered. As listed above in Tables 1 and 2, the DCM and 
DM protocols support configuration of and reporting of 
diagnostic information concerning silent and non silent 
packets. The reporting of silent packets can be used to 
implement disconnect supervision in an IP/PSTN gateway 
connection environment. In a similar fashion, the detection 
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of non silent packets can be used to implement answer 1108. Thea, the coimter is incremented at step 1110. If the 

detection in an IP/PSTN gateway connection. time limit has not expired at a step 1112, monitoring 

According to the present invention, silent and non-silent continues as shown generally at a loop 1114. If time has 

detection can occur once an IP connection is established expired at a step 1116, either the average is calculated at step 
between two or more TEs, as shown at a step 1002, Asilence s 1118 or the total is calculated at a step 1120, If a predeter- 

counter and non-silence counter, as well as a start timer, are mined average or total event limit is not exceeded at a step 

initiahzed at a step 1004. Detection of cither silent packets 1^22, the timer and counter are simply reinitiahzed and the 

or non-silent packets is performed at a step 1006. If a silent process continues, as shown generally at a loop 1124. If an 

packet is detected, the silent counter is incremented, as average or total event limit is exceeded, then the HE per- 

shown at a step 1008. Similarly, if a non-silent packet is forming the detection of diagnostic parameters transmits a 

detected, the non-silent counter is implemented at a step DM to the DS (or other device as configured by the DCM), 

1010. If a predetermined limit of the timer has not expired, as shown at a step 1126. The detection process continues for 

as detected at a step 1012, silent and non-silent packet the parameter of interest as shown generally at a loop 1128. 

detection is continued, as shown generally at a loop 1014. If The detection/monitoring of diagnostic parameters can be 
the timer Umit has expired, the silent packet percentage or ^5 performed by one or more TEs involved in an IP connection, 

non-silent package percentage is calculated at a step 1016. Any given TE can perform diagnostic parameter detection/ 

Predetermined limits for non-packet percentage and non- monitoring for any given parameter. The type of calculation 
silent-packet percentage are set a priori by a DCM in order (average or total count) and the time and total count Hmits 
to determine, in the case of the silent packet percentage are set according to the network administrator via DCMs, as 
Umit, whether a disconnection has occurred. Alternatively, if described above in connection with Table 1. 
the predetermined non-silent packet percentage limit has Another embodiment of the present invention taking 
been met, then answer detection has been determined. These advantage of diagnostic information is called "attendant 
limits are checked at a step 1018. If a limit is not met and supervision." FIG. 12 illustrates various types of TEs in a 
the timer period has expired, the counters and start timer are system for attendant supervision of IP connections accord- 
reinitialized and the detection process continues, as shown ing to the present invention. FIG, 12 illustrates various TEs 
generally at a loop 1020, If a limit has been met, the TE at 800, These TEs can take on various configurations as 
detecting the Umit wiU send a DM to the Diagnostic Super- discussed above in connection with FIG. 2. The TEs com- 
visor (DS), as shown at a step 1022. The detection process municate via the Internet 110. In this embodiment, one or 
will then continue as shown generally at a loop 1024. more attendants (A, B through n) are shown at 1204. TEs 

Calculating the percentage of total packets is a straight- 800 and one or more attendants 1204 comprise a commu- 

forward process. Total percentage of silent packets is simply nications network. At an attendant 1204 a human operator 

the total number of silent packets divided by the sum of the (called the "attendant") can monitor IP connections by TEs 

total number of silent and non-silent packets. Similarly, the 800. 

percentage of non-silent packets is the total number of Using an information element format similar, to those 

non-silent packets divided by the sum of the total number of described above in connection with the DCMs and DMs 

silent packets and non-silent packets. Rather than calculat- (Usted in Tables 1 and 2), an attendant 1204 can function as 

ing the average packet count, the process can be simplified a diagnostic supervisor to provide real-time connection 

by simply counting the total number of silent or non -silent supervision. For example, diagnostic information can be 

packets over a finite period of time. provided to an attendant 1204 concerning whether a user at 

In an alternative embodiment of the present invention, a TE is currently on the phone and unable to take an 

DCM configuration information can be preprogrammed at incoming caU, Based on this information the attendant 1204 

installation. In this manner TEs are hard-coded to transmit can answer the incoming caU and alert the caller that tiie TE 

DMs that include diagnostic information of parameters is currentiy on another call, or is otherwise generally 

without the need to be actively configured by DCMs. For unavailable. Alternatively, diagnostic information can be 

example, TEs would automatically (e.g., at predetermined transmitted to the attendant 1204 from a TE if that TE wishes 

time intervals) transmit DMs with sUent and non-silent to forward all incoming calls to the attendant 1204. In this 

diagnostic information during all or only preprogrammed maimer the attendant 1204 can answer all forwarded calls 

types of connections. intended for that TE. The attendant 1204 can view the status 

RG- 11 illustrates an exemplary flow diagram for moni- 50 (^^1 information) of network users on the screen of an 

toring connection perimeters of IP connections according to attendant's computer, workstation, or on an intelligent IP 

the present invention. In addition to sUent and non-silent phone, for example. The computer, workstation, or intelU- 

packet detection, other diagnostic parameters can also be gent IP phone provides an interface for the attendant 1204 to 

monitored on an average or total event approach. The flow monitor telephone network calls, or the like, 
diagram of FIG. 11 illustrates both approaches. Parameters 55 The one or more attendants 1204 are therefore capable of 

that can be measured according to an average packet count performing similar call functions that a operator of a com- 

include jitter, and playout delay. Parameters that can be munications system can perform. Although the communi- 

monitored on a total event basis include the number of cation network is comprised of TEs and attendants that are 

packets, dropped packets, invalid header packets, micro- located at different geographical locations, call information 

overflow, missing payload, and lost packets that were can be sent to the attendant or attendants in the same manner 

replaced by preceding packets. As would be apparent to one that diagnostic information is transferred to the DS in the 

skiUed in the relevant art, these Usted parameters are pro- previously discussed embodiments, 

vided by way of example and not Umitation. FIG. 13 illustrates various types of TEs in a system for 

The detection of diagnostic parameters begins once an IP billing management of Internet connections according to the 
connection is established, as shown at step 1102. A timer and 65 present invention. In this embodiment, one or more billing 

counter are initialized in a step 1104. The parameter being managers (A, B through n) 1302 coUect and process bilUng 

monitored is read at a step 1106 and its value stored at a step information for IP connections over the Internet 110 by the 
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TEs 800. In a similar manner in which call information is enable the computer system to perform certain features of 

provided to attendants 1204 in the embodiment shown in the present invention as discussed herein. In particular, the 

FIG. 12, a billing protocol can be established for transmit- computer programs, when executed, enable the processor to 

ting billing infonnation to the billing manager 1302. The perform features of the present invention. Accordingly, such 
billing protocol would comprise a similar syntax as the s computer programs represent controllers of the computer 

information element formats for DCMs and DMs as system. 

described above in connection with Tables 1 and 2, Billing a° embodiment where the invention is implemented 

for IP connection services can be achieved in this manner. ^^ing software, the software can be stored in a computer 

program and loaded into the computer system using the 
in. HARDWARE AND SOFTWARE jq removable storage drive, the hard drive or the communica- 

IMPLEMENTATIONS tions interface. The control logic (software), when executed 

. by the processor, causes the processor to perform certain 

Ihe various managers, controllers and generators of the functions of the invention as described herein, 

present invention can perform specific features, which in ^^^^^^ embodiment, features of the invention are 

effect compnse a computer system or portions thereof. Such implemented primarily in hardware using, for example, 
a computer system includes, for example, one or more 15 hardware components such as appUcation specific integrated 

processors that arc connected to a communication bus. circuits (ASICs) and the like. Implementation of the hard- 

Although telephony-specific hardware can be used to imple- ware state machine so as to perform the functions described 

ment the present invention, the following description of a herein will be apparent to persons skilled in the relevant 

general purpose computer system is provided for complete- art(s). 

ness. ^0 In yet another embodiment, features of the invention can 

The computer system can also include main memory and be implemented using a combination of both hardware and 

can also include secondary memory. The secondary memory software, 

can include, for example, a hard disk drive and/or a remov- ly CONCLUSION 

able storage drive, representing a floppy disk drive a ^^^^ ^^^^^^ embodiments of the present invention have 

magnetic tape drive, an optical disk drive, and the like. Tlie ^^^^ ^^^^-^^ ^^^^^ understood that they have 

removab e storage drive reads from and/or writes to a been presented by way of example, and not limitation. It will 

removable storage unit m a well known manner. The remov- ^e apparent to persons skilled in the relevant art that various 

able storage unit, represents a floppy disk, magnetic tape, changes in form and detail can be made therein without 

optical disk, and the like, which is read by and written to by departing from the spirit and scope of the invention. Thus the 

the removable storage drive. The removable storage unit present invention should not be limited by any of the 

includes a computer usable storage medium having stored above-described exemplary embodiments, but should be 

therein computer software and/or data. defined only in accordance with the following claims and 

The secondary memory can include other similar means tbeir equivalents. All cited patent documents and publica- 

for allowing computer programs or other instmctions to be tions in the above description are incorporated herein by 

loaded into the computer system. Such means can include, reference, 

for example, a removable storage unit and an interface to What is claimed is: 

remote storage and the like. Examples of such can include } ^ ^^^^^^^ managing diagnostic and performance 

a program cartridge and cartridge interface (such as that ^5?^^^^^°° communications system terminal endpomts 

found in video game devices), a removable memory chip ^^f'^ communicating over an Internet Protocol (IP) 

(such as an EPROM, or PROM) and associated socket, and comprising the steps of: 

other removable storage units and interfaces which allow transmitting a Diagnostic Configuration Message (DCM) 

software and data to be transferred from the removable from a Diagnostic Suprvisor (DS) to the TEs, wherem 



storage unit to the computer system. 



the DS is capable of being coupled to the communica- 
tions systems; 

The computer system can also include a communications 45 generating Diagnostic Messages pMs) at the TEs based 

mterface. The communications mterface allows software diagnostic information concerning IP network con- 

and data to be transferred between the computer system and nections in which the TEs participate, wherein said 

external devices. Examples of communications interfaces dCM instructs the TEs how to format and under what 

include, but are not limited to a modem, a network interface criteria to transmit said DMs; and 

(such as an Ethernet card) a communications port, a PCM- 50 transmitting said DMs from said TEs to said DS or to a 

CIA slot and card, etc. Software and data transferred via the plurality of DSs 

communications interface arc in the form of signals which 2. The method according to claim 1, further comprising 

can be electronic, electromagnetic, opUcal or other signals ^^^^ transmitting said DMs to one or more TEs. 

capable of being received by the commumcations interface. 3 ^^^^^^ according to claim 1, further comprising 

These signals are provided to commumcations interface via 55 j^e step of providing the DS with TE communication 

a channel that can be implemented using wire or cable, fiber capabilities 

optics a phone hue, a cellular phone link, an RF link, and 4 ^he method according to claim 1, farther comprising 

the step of providing the TEs with DS capabilities. 

In this document, the terms "computer program medium" 5. The method according to claim 1, further comprising 
and "computer usable medium" are used to generally refer the step of generating diagnostic reports based on said DMs. 
to media such as a removable storage device, and a hard disk 6. The method according to claim 1, wherein said con- 
drive. Computer programs are means for providing software nections are voice, modem, facsimile, video or data trans- 
to the computer system. missions. 

Computer programs (also called computer control logic) 7. The method according to claim 6, wherein said diag- 

are stored in the main memory and/or secondary memory. 65 nostic infonnation comprises error statistics, voice statistics, 

Computer programs can also be received via the communi- modem statistics, facsimile statistics, video statistics or data 

cations interface. Such computer programs, when executed, statistics. 
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8. The method according to claim 1, further comprising a Configuration Manager; 
the step of rerouting an IP network connection between two ^ Report Manager; 
"^L^^J^^ '° the public switched telephone network ^ Real-Time Response Manager; and 
(PSTN) based on said diagnostic mionnation, zt * # 

9. The method according to claim 8, wherein said rerout- 5 Input/Output (I/O) Manager. 

ing is initiated by the DS ^* system according to claim 22, wherein said DS 

10. The method according to claim 8, wherein said ^"r^ber comprises a communications system. 

rerouting is initiated by a TE. Th^ system according to claim 22, wherein said 1/0 

11. The method according to claim 8, wherein said manager is coupled to the IP network and the public 
rerouting is initiated by a TE with DS capabilities. switched telephone network (PSTN). 

12. The method according to claim 8, wherein said 25. The system according to claim 21, wherein 
rerouting is initiated by a TE user, a network administrator said a plurality of TEs use the IP network for voice, 
or a communications system attendant. modem, facsimile, video or data transmissions, and 

13. Tlie method according to claim 1, further comprising diagnostic information comprises error statistics, 
step of configuring DCNb to instruct TEs to transmit ^^.^ ^^^^^^ ^^^^^^ ^^^^^ ^^^^ ^^^^^^ 

DMs including silent packet diagnostic information. statistics 

14. The method according to claim 13, further comprising *^r™ ' , i-^^ i_ - 

the step of providing disconnect supervision using said silent „ 26. The system aca)rding to claim 21 wherein said 

packet diagnostic information. Real-Tune Response Manager reroutes an IP network con- 

15. The method according to claim 1, further comprising '>°° w° '° ^^^^ ^^-"^"^ 
the step of configuring DCMs to instruct TEs to transmit 20 telephone network (PSTO) based on said diagnostic mfor- 
DMs including non-silent packet diagnostic information. "^^^^'^^ .. , . ^* , • 

16. The method according to claim 15, fiirther comprising 27 The system according to claim 22 wherem said 
the step of providing answer detection using said non-silent Configuration Manager configures said DCMs to msltxict 
packet diagnostic information. o^^, J, «f said plurabty of TEs to transmit DMs 

17. -nie method according to claim 1, further comprising 25 "^""If'^ ^^^^^^ P^^^^^ diagnostic information. 

the step of providing attendant supeivision of the commu- ^8. The system according to claim 27, wherem said 

nications system, wherein a human attendant provides real- R^al-Tmie Response Manager provides disconnect supervi- 

time response to said diagnostic information. ^'^^ ^^^S ^^'^ ^^1^'^^ P^^^^^ diagnostic mformation. 

18. The method according to claim 1, further comprising ^9. The system according to claim 22, wherem said 
the step of providing billing management of the communi- 30 Configuranon Manager configures said DCMs to mstnict 
cations system, wherein bilhng of an IP network connection '"o^e ^^^^ Pl^^ality of TEs to transmit DMs 
is performed based on said diagnostic information. ^'^H^^^S non-silent packet diagnosUc infomaation. 

19. The method according to claim 8, further comprising The system according to claim 29, wherem said 
the step of providing billing management of the communi- R^al-Time Response Manager provides answer detection 
cations system, wherein biUing for said rerouting is per- 35 ^^^^S ^aid non-silent packet diagnostic mformation. 
formed based on said diagnostic information. ^1. The system according to claim 21, wherem said DS 

20. The method according to claim 1, wherein said comprises an mterfacc for attendant supervision of the 
diagnostic information comprises a plurality of parameters communications system, enablmg a human attendant to 
defined by the DCMs and the DMs, and said method further provide real-time response to said dia^ostic informaUon. 
comprising the step of determining, over a predetermined 40 32. Tlie system according to claim 21, wherem said DS 
time period, at least one of: comprises a biUing manager for the communications system, 

. r r f -J 1 V* thereby enabling billing of IP network connections based on 

an average number of occurrences of one of said plurality J . 

of arameters ^ diagnosUc mformation. 

" ' - ^.jii-^i. 33. The system according to claim 26, wherein said DS 

a percentage of occurrences of one or said plurality of • lmv .l *• * 

a ^vivwiiagv, uvvuiivii*^ uiiv vjl oaivi ^.luiaiitjr compriscs a bilfiug mauagcr for thc communicatioos systcm, 

parameters, thereby enabling billing of said rerouting based on said 

a maximum number of occurrences of one or said plu- diagnostic information, 

rality of parameters, and 34 j^e system according to claim 22, wherein said 

an actual number of occurrences of one of said plurality diagnostic information comprises a plurality of parameters 

of parameters. defined by the DCMs and the DMs, and said Real-Time 

21. A system for managing diagnostic information for a Response Manager acts on said diagnostic information by 
communications system, comprising: determining an actual number of occuacnces of one of said 

a pluraUty of terminal endpoints (TEs) capable of com- plurality of parameters, 

municating over an Internet Protocol (IP) network; and 35. A computer program product comprising a computer 
a Diagnostic Supervisor (DS) capable of being coupled to 55 usable medium having control logic stored therein for caus- 

the IP network, ing a computer to manage diagnostic and performance 

wherein said DS transmits a Diagnostic Configuration information for communications system terminal endpoints 

Message (DCM) to said TEs, (TEs) communicating over an Internet Protocol (IP) 

wherein one or more of said TEs generate Diagnostic network, said control logic comprising: 

Messages (DMs) based on diagnostic information con- 60 a first computer readable program code means for causing 

cerning IP network connections in which said one or the computer to transmit a Diagnostic Configuration 

more of said TEs participate, and Message (DCM) from a Diagnostic Supervisor (DS) to 

wherein said DCM instructs the TEs how to format and the TEs, wherein the DS is capable of being coupled to 

when to transmit said DM to said DS or to a plurality the communications systems; 

of DSs and TEs. 65 a second computer readable program code means for 

22. The system according to claim 21, wherein said DS causing the computer to generate Diagnostic Messages 
comprises at least one of: (DMs) at the TEs based on diagnostic information 
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concerning IP network connections in which the TEs 47. The computer program product according to daim35, 

participate, wherein said DCM instructs the TEs how to further comprising a fourth computer readable program code 

format and under what criteria to transmit said DMs; means for causing the computer to configure said DCMs to 

instruct TEs to transmit DMs including silent packet diag- 

a third computer readable program code means for caus- ^ nostic information, 

ing the computer to transmit said DMs from said TEs 48. The computer program product according to claim 47, 

to said DS or to a plurality of DSs. further comprising a fifth computer readable program code 

36. The computer program product according to claim 35, uj^ans for causing the computer to provide disconnect 
further comprising a fourth computer readable program code supervision using said silent packet diagnostic information, 
means forcausing the computer to transmit said DMs to one 10 computer program product according to claim 35, 

^'^ili^I^ . J . J- . t • -11. further comprising a fourth computer readable program code 

37. Tie computer program product according to claim 35, ^^^^^ ^^^^ ^^ O^Ms to 

further comprising a fourth computer readable program code . , . * . • i j- •» . i * 

c ' . . J T^c^ ... mstruct TEs to transnut DMs mcludmg non-silent packet 

means for causing the computer to provide the DSs with TE - r 

communication capabilities. 35 daa^ostic information. 

38. The computer program product according to claim 35, ^ ^J" ^°?P^^^^ P^^^^^ ^^^l^""^ 

tether comprising a fourth computer readable program code comprising a fifth computer readable program code 

means for causing the computer to provide the TEs with DS ^^^^ns for causing the computer to providing answer detec- 

cap abilities. using said non -silent packet diagnostic information. 

39. The computer program product according to claim 35, 51. The computer program product according to claim 35, 
further comprising a fourth computer readable program code further comprising a fourth computer readable program code 
means for causing the computer to generate diagnostic means for causing the computer to provide attendant super- 
reports based on said DMs. vision of the communications system, wherein a human 

40. The computer program product according to claim 35, attendant provides real-time response to said diagnostic 
wherein said connections are voice, modem, facsimile, 25 information. 

video or data transmissions. 52. The computer program product according to claim 35, 

41. The computer program product according to claim 40, further comprising a fourth computer readable program code 
wherein said diagnostic information comprises error means for causing the computer to provide billing manage- 
statistics, voice statistics, modem statistics, facsimile ment of the commimications system, wherein billing of an IP 
statistics, video statistics or data statistics. ^0 network connection is performed based on said diagnostic 

42. The computer program product according to claim 35, information 

further comprising a fourth computer readable program code 53 computer program product according to claim 42, 

means for causing the computer to reroute an IP network ^^^^^^ comprising a fifth computer readable program code 

connection between two or more TEs to the pubuc switched r ■ *u * * -j u-n- 

, , , ^oT-vT\ i_ J -J / • f means for causing the computer to provide bilhng manage- 

telephone network (PSTN) based on said diagnostic infor- , • . u • uw a 

mation ment of the communications system, wherem billmg for said 

43! The computer program product according to claim 42, '^'^f^ performed based on said diagnostic information, 

wherein said rerouting is initiated by the DS. ^4. The computer program product according to claim 35 

44. The computer program product according to claim 42, "^^^^^in said diagnostic information comprises a plurality of 
wherein said rerouting is initiated by a TE, ^0 parameters defined by the DCMs and the DMs, and said 

45. The computer program product according to claim 42, computer program product further comprises a fourth com- 
wherein said rerouting is initiated by a TE with DS capa- P^ter readable program code means for causing the com- 
bilities. puter to determine an actual number of occurrences of one 

46. The computer program product according to claim 42, of said plurality of parameters, 
wherein said rerouting is initiated by a TE user, a network ^5 

administrator or a communications system attendant. ♦ ♦ * ♦ ♦ 



11/18/2003. EAST Version: 1.4.1 



